Agent 走到哪了——从 2026 年回头看《LLM Powered Autonomous Agents》

这两年 AI 发展得越来越快了，就像别人开玩笑说的，AI 时代里，只要你学得慢，你就可以不用学了。

回头再看 Lilian Weng 在 2023 年写的《LLM Powered Autonomous Agents》，我反而觉得有些东西没有那么快过时。模型变强了，工具链变复杂了，产品形态也换了几轮，但 Agent 的一些基本问题，今天仍然绕不开。

这篇文章就从 2026 年的视角回头看：当年那套 Agent 路线还成立吗？哪些方向已经被验证？哪些想象被修正了？又有哪些问题，到现在依然没有真正解决？

关于原文内容的解读，参见：《Agent 不只是一个更长的 Prompt》

1. 2023 年的 Agent 路线过时了吗？

我的判断是：没有过时。

Lilian Weng 当时总结的核心框架是：

Agent = LLM as Brain
      + Planning
      + Memory
      + Tool Use

这个框架放到 2026 年看，依然是成立的。甚至可以说，今天绝大多数 Agent 产品和开发框架，还是在这条主线上展开。

无论是代码 Agent、研究 Agent、浏览器 Agent、办公自动化 Agent，还是企业里的客服、销售、工单和数据分析 Agent，本质上都离不开这几件事：

理解目标
规划步骤
保存上下文
调用工具
观察结果
修正行动

只是有一点变化很明显：我们对 Agent 的想象变得更冷静了。

2023 年的 Agent 很容易被想象成“模型自己循环、自己想办法、自己把事情做完”。到了 2026 年，真正能落地的 Agent 更像是一个受控的软件执行系统。

也就是说，大家不再只问：

模型能不能自己想出下一步？

而是开始认真问：

工具调用可靠吗？
权限边界清楚吗？
过程能追踪吗？
失败能恢复吗？
结果能验证吗？
关键节点能不能让人介入？

所以，2023 年那篇文章没有过时。只是今天再读它，我们需要把里面的“自主”二字，放回更工程化、更可控的语境里理解。

---

2. 最大变化：Agent 不再只是 Prompt

早期 Agent 很多时候像一个复杂 prompt：

你是一个自主 Agent。
你需要思考、行动、观察、反思。
请按照 Thought / Action / Observation 格式执行。

这种方式很适合做 demo。它直观，容易展示，也很能激发想象力。但它的问题也很明显：脆。

模型可能输出格式错了，工具名称写错了，参数填错了，任务目标忘了，或者在一个看似有逻辑的循环里越走越偏。很多早期 Agent 的“自主”，其实更像是把不稳定性自动化了。

到了 2026 年，Agent 越来越不像一个 prompt 技巧，而更像一个软件系统。一个比较现代的 Agent，通常会包含这些东西：

LLM 推理器
工具 schema
状态管理
执行环境
权限控制
日志追踪
评测系统
人工确认机制

这意味着 Agent 的核心问题已经从“模型能不能想出来”，扩展成了：

系统能不能稳定执行？
工具能不能安全调用？
状态能不能长期保存？
错误能不能被发现和恢复？
高风险操作能不能被拦住？

这大概是 2026 年看 Agent 时最重要的变化。我们终于不再把 Agent 主要看作一段高级提示词，而是把它看作一个带模型的执行系统。

---

3. 哪些方向已经被验证？

3.1 Tool Use 被彻底验证了

2023 年那篇文章里说，LLM 需要工具来弥补自身限制。今天看，这一点已经被充分验证。

原因很简单：模型本身并不能直接接触世界。它不知道实时信息，不能自己执行代码，不能访问本地文件，不能直接查数据库，也不能天然操作浏览器和企业系统。

如果没有工具，模型只能在语言里模拟行动。有了工具，它才可能真的去查资料、跑代码、读文件、调用 API、修改系统状态。

今天主流 Agent 几乎都会配备各种工具：

搜索
文件读取
代码执行
数据库查询
浏览器操作
命令行
API 调用
企业内部系统

所以 Tool Use 已经从研究概念变成了 Agent 的基础设施。现在真正难的，已经不是“要不要工具”，而是：

工具接口怎么定义？
工具权限怎么限制？
参数怎么校验？
失败怎么处理？
调用过程怎么记录？
工具返回的结果怎么验证？

换句话说，工具让 Agent 有了手脚，但手脚怎么受控，才是工程落地里的大问题。

---

3.2 Coding Agent 是最先成熟的方向之一

到 2026 年，代码 Agent 可以说是最成熟的 Agent 形态之一。

这不是偶然。代码任务天然适合 Agent，因为代码世界有非常清楚的反馈机制：

编译器
类型检查
单元测试
运行日志
Lint
Git diff
CI/CD

Agent 修改代码之后，可以运行测试；测试失败了，可以读取报错；定位到问题后，再继续修改。这个过程正好符合 ReAct 的模式：

Thought → Action → Observation → Replan

一个典型代码 Agent 的工作流大概是：

理解 issue
  ↓
搜索相关代码
  ↓
修改文件
  ↓
运行测试
  ↓
根据错误继续修复
  ↓
总结改动

这也是为什么代码 Agent 的体验提升很快。它不只是因为模型更会写代码了，更因为代码环境本身会不断给它反馈。

这给我的启发是：

越是有明确反馈和验证机制的领域，越适合 Agent 先落地。

如果一个领域没有测试、没有日志、没有可校验的结果，只靠模型自己判断“我做得对不对”，那 Agent 就会脆很多。

---

3.3 结构化工具调用缓解了早期脆弱性

早期 Agent 经常用自然语言格式调用工具，比如：

Action: Search["xxx"]

然后程序再去解析模型输出。

这种方式看起来优雅，其实很容易出错。模型多写一个符号、少写一个括号，或者把解释文字混进工具调用里，整个流程就可能坏掉。

现在主流 Agent 更倾向于结构化工具调用：

工具名称
参数 schema
返回值 schema
错误信息
权限声明

这让工具调用更像正常的软件接口，而不是靠解析一段自然语言来碰运气。

它确实解决了不少工程问题：

格式更稳定
参数更可校验
错误更容易处理
日志更容易记录
权限更容易控制

不过也要注意，结构化调用只是解决了“怎么调用”的可靠性，不等于解决了“该不该调用”和“调用结果是否正确”的问题。

模型仍然可能选错工具、填错参数，或者误解工具返回的内容。接口稳定了，只是把问题往更深处推进了一层。

---

3.4 长上下文缓解了短期记忆瓶颈

2023 年 Agent 的一个明显限制，是上下文窗口不够。任务稍微一长，模型就容易忘记前面做过什么。

到 2026 年，长上下文模型已经明显缓解了这个问题。Agent 可以一次性读取更多内容：

代码库片段
长文档
日志
历史对话
工具返回结果
任务计划

这让很多过去很难做的任务变得可行。比如一次性读更多代码，理解更长的设计文档，或者在同一个任务里保留更多中间状态。

但长上下文不是万能的。它解决的是：

能看更多内容

没有彻底解决：

哪些内容重要
哪些内容过期
哪些内容互相冲突
哪些内容应该长期保存
哪些内容应该被遗忘

所以长上下文缓解了短期记忆问题，却没有真正解决长期记忆问题。看得更多，不等于记得更好，也不等于理解得更稳。

---

4. 哪些方向被修正了？

4.1 “完全自主 Agent”的想象被降温了

2023 年前后，很多人对 Agent 的想象大概是：

给它一个目标，它自己搞定一切。

AutoGPT 这类项目就很能代表这种想象。它们很有魅力，因为它们把“自主 AI 助手”的愿景直接摆到了眼前。

但几年之后再看，完全自主的通用 Agent 仍然不稳定。问题包括：

容易目标漂移
容易陷入循环
长期规划不可靠
工具调用可能出错
成本不可控
失败后不一定会恢复
高风险操作需要人类确认

所以 2026 年更现实的方向，不是把所有事情都交给 Agent，而是：

人设定目标
Agent 执行大部分步骤
人在关键节点监督或确认
Agent 根据反馈继续推进

也就是 human-in-the-loop。

我现在更愿意相信：真正成熟的 Agent，不是最自由的 Agent，而是能在正确边界内稳定行动的 Agent。

---

4.2 Memory 不再等同于向量数据库

2023 年很常见的一种理解是：

长期记忆 = 向量数据库

今天看，这个理解太简单了。

向量数据库能解决的是“把相关内容找回来”，但 Agent 的记忆远不止检索。一个真正有用的 Agent Memory，至少会涉及：

事实记忆：用户是谁、项目是什么、配置是什么
经验记忆：之前哪些方案成功或失败
工作记忆：当前任务进行到哪一步
状态记忆：文件改了什么、工具执行到哪
偏好记忆：用户喜欢什么风格、有什么约束
权限记忆：哪些操作可以自动做，哪些必须确认

这些东西加起来，更像是一个状态管理系统，而不只是一个 RAG 检索库。

未来 Agent 的长期记忆仍然要面对很多麻烦问题：

记忆如何形成
记忆如何更新
错误记忆如何删除
冲突记忆如何处理
过期记忆如何遗忘
敏感记忆如何保护

这也是为什么我觉得 Memory 仍然是 Agent 里最难的部分之一。它不只是技术问题，也是产品设计、安全治理和用户信任的问题。

---

4.3 Reflection 不再被神化

早期 Agent 很强调 Self-Reflection。让模型自己反思错误、总结经验、重新尝试，确实能提升一些任务表现。

但今天看，Reflection 不是万能药。

模型可能不知道自己错在哪里，也可能错误归因。更麻烦的是，它有时会非常自信地给出一段“看起来很合理”的反思，但那段反思本身就是错的。

所以更可靠的方式，不是单纯让模型“多反思几遍”，而是把 Reflection 放进外部验证流程里：

Reflection + 单元测试
Reflection + 编译器
Reflection + 运行日志
Reflection + 规则校验
Reflection + 人工审核
Reflection + 可回滚机制

这样看，Reflection 不再是一个神奇的 prompt 技巧，而是错误恢复流程的一部分。它负责提出下一步假设，但最终还是要靠外部世界来验证。

---

4.4 Multi-Agent 不是越多越好

多 Agent 一度很流行。常见设计是：

Planner Agent
Researcher Agent
Coder Agent
Reviewer Agent
Critic Agent
Executor Agent

这种分工在一些任务里确实有价值，尤其适合并行搜索、多方案比较、代码审查、复杂研究，或者模拟不同角色之间的协作。

但多 Agent 也会带来自己的麻烦：

成本更高
通信更复杂
上下文更混乱
错误可能互相放大
责任边界不清
调试更困难

所以 2026 年更实际的经验是：

能用简单 workflow 解决的，不要强行 multi-agent；只有在确实需要分工、并行、互评时，再引入多个 Agent。

多 Agent 是工具，不是目的。它能解决复杂性，也会制造复杂性。

---

5. 哪些问题仍然没有解决？

5.1 长程自主规划仍然困难

Agent 现在可以完成很多短中程任务，但长程自主仍然困难。

所谓长程任务，不只是步骤多。它通常还意味着：

跨天持续执行
跨多个系统协作
中途遇到异常
任务目标可能变化
需要长期维护状态
需要判断什么时候停止
需要判断什么时候问人

比如：

长期维护一个代码项目
连续管理一套复杂服务器
持续跟踪一个研究主题
自动处理一整套企业流程

这些任务对 Agent 来说仍然很难。因为它不仅需要规划，还需要稳定保持目标、处理异常、管理长期记忆、控制权限，并且持续验证结果。

短任务里，模型可以靠局部反馈不断修正；长任务里，任何一个小偏差都可能在后面被放大。

---

5.2 可靠长期记忆仍然困难

长期记忆仍然是 Agent 的核心难题之一。

一个 Agent 如果要长期为用户工作，就必须能记住：

用户偏好
项目背景
历史决策
失败经验
当前任务状态
长期目标
工具使用习惯

但记忆系统很容易出问题：

错误信息被记住怎么办？
过期信息没有删除怎么办？
两条记忆冲突怎么办？
用户隐私如何保护？
哪些信息应该记，哪些不该记？
模型如何知道该检索哪段记忆？

这些问题说明，Agent Memory 不是单纯的数据库问题。它还涉及产品边界、安全策略，甚至涉及用户是否愿意让一个系统长期记住自己。

---

5.3 Agent 安全和权限控制仍然是大问题

Agent 一旦能调用工具，就会产生真实影响。

如果它只能聊天，说错了最多是答案错。但如果它能操作文件、发邮件、调用 API、执行命令，风险就完全不同了。

可能的问题包括：

误删文件
误发邮件
错误提交代码
泄露隐私数据
被网页 prompt injection 攻击
越权调用工具
执行危险命令
错误操作账户

因此，Agent 必须有权限边界。

一个成熟 Agent 至少需要：

最小权限原则
沙盒环境
高风险操作确认
操作日志
可回滚机制
敏感信息保护
工具权限隔离
异常行为检测

未来 Agent 的竞争力，不只是模型有多强，而是系统有多安全、多可控。尤其在企业场景里，可控性往往比“看起来很智能”更重要。

---

5.4 评测仍然不够完善

Agent 的评测比普通 LLM 难得多。

普通问答模型很多时候只看：

最终答案对不对

而 Agent 要看整个过程：

计划是否合理
工具是否选对
参数是否填对
是否遵守规则
是否能处理异常
是否能恢复失败
成本是否可控
是否触发了不该触发的操作

也就是说，Agent 的评测应该是过程评测，而不只是结果评测。

这也是为什么真实 Agent 落地时，日志、trace、测试集、模拟环境和人工审核都很重要。没有这些东西，就很难判断一个 Agent 是真的可靠，还是只是这次运气不错。

---

6. 2026 年的 Agent 应该怎么理解？

如果说 2023 年的 Agent 可以概括为：

Agent = LLM + Planning + Memory + Tool Use

那么 2026 年更准确的版本可能是：

Agent = LLM 推理器
      + 工具接口
      + 状态管理
      + 任务规划
      + 上下文 / 记忆系统
      + 执行环境
      + 权限控制
      + 评测体系
      + 追踪日志
      + 人工介入机制

这意味着 Agent 开发越来越像软件工程。

我们不能只问：

模型聪不聪明？

还要问：

工具是否可靠？
状态是否清晰？
权限是否受控？
失败是否能恢复？
过程是否可审计？
人是否能介入？
结果是否可验证？

模型能力当然重要，但它只是系统的一部分。真正能长期工作的 Agent，一定要把模型放进一个可观察、可控制、可恢复的执行环境里。

---

7. 对个人开发者的启发

如果自己想做一个 Agent，我觉得不要一上来就追求“全自动”。

更现实的路线是：

1. 先限定任务范围
2. 只提供必要工具
3. 使用结构化工具调用
4. 保留完整日志
5. 高风险操作必须确认
6. 引入测试或验证机制
7. 为失败设计恢复流程
8. 为长期任务设计状态存储

一个实用 Agent 的设计思路可以是：

User Goal
  ↓
Planner
  ↓
Task State
  ↓
Tool Router
  ↓
Tool Execution
  ↓
Observation
  ↓
Verifier
  ↓
Reflection / Replanning
  ↓
Final Response

这里最重要的不是让模型自由发挥，而是让模型在明确边界内行动。

这听起来好像没有“全自动 Agent”那么性感，但它更接近真实可用的方向。很多时候，稳定地完成一个小范围任务，比偶尔神奇地完成一个大任务更有价值。

---

8. 总结：Agent 的路线没变，但理解变深了

从 2026 年回头看，Lilian Weng 这篇文章的主线仍然成立。

它提出的三个核心组件：

Planning
Memory
Tool Use

仍然是今天 Agent 系统的基础。

但三年之后，我们对 Agent 的理解确实变了：

从 Prompt 技巧到系统工程
从完全自主到可控自主
从向量记忆到状态管理
从自我反思到外部验证
从 Demo 展示到过程评测

所以这篇文章没有过时。它更像是一张早期地图：方向仍然对，只是今天我们更清楚，路上真正难走的地方在哪里。

如果用一句话概括我现在的理解：

真正成熟的 Agent，不是最自由的 Agent，而是能在明确边界内稳定、可靠、可控地完成任务的系统。

这也是我从 2026 年回头看这篇文章得到的最大启发。